Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup tpu/tvu runtime description in the runtime chapter. #2737

Merged
merged 1 commit into from
Feb 20, 2019

Conversation

aeyakovenko
Copy link
Member

Problem

TPU and TVU have a slightly different runtime.

Summary of Changes

Cleanup the runtime and some of the wording in the doc.

Fixes #

@aeyakovenko aeyakovenko changed the title Cleanup tpu/tvu runtime Cleanup tpu/tvu runtime description in the runtime chapter. Feb 12, 2019
The TVU runtime ensures that PoH verification occurs before the runtime
processes any transactions.

<img alt="Runtime pipeline" src="img/tvu-runtime.svg" class="center"/>

At the *execute* stage, the loaded pages have no data dependencies, so all the
programs can be executed in parallel.

The runtime enforces the following rules:

1. Only the *owner* program may modify the contents of an account. This means
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not following this rule, what is it trying to accomplish?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jackcmay thats the current design, the account has a owner program id, only the owner program id can modify the account userdata byte array.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that means that a program has a guarantee that the program code is the only thing that can transition state in the accounts that it owns.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I get that part but rule #1's second part is confusing and muddles up the first part. How about:
"1. Each account is owned and modifiable by only one program at a time."

For the second half are you saying that when an account is assigned it's user data is zero'd?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jackcmay yes! :), and cannot be reassigned.

book/src/runtime.md Outdated Show resolved Hide resolved
* `Move` - moves tokens between accounts.

* `Spawn` - spawns a new program from an account.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might want to expand on what this means. Aka, marks the account as executable, that its userdata contains the programs bits that are executed, and that it contains a reference to the loader that will execute it.

@@ -70,14 +81,19 @@ encodes.
instructions to create memory before passing it to another program. This
instruction can be composed into a single transaction with the call to the
program itself.

2. Runtime guarantees that when memory is assigned to the program it is zero
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are specifically referring to "CreateAccount"? Might want to make that explicit that there is no other time the memory is zero'd?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you mean? Assign or CreateAccount will enforce that the userdata is zero.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems strange to zero on assign. Could see use cases where an account is passed between programs and carrying state with it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jackcmay you can pass state with a copy. The program code must accept the copy and actually do it. Otherwise you can trick the program into an unintended state transition since the program would have no way of distinguishing an "assigned' dirty state, from a state it natively generated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added notes on state security

5. Runtime guarantees the balances belonging to accounts are balanced before
and after the transaction

6. Runtime guarantees that multiple instructions all executed successfully when
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"multiple"? Or "all" instructions are successfully executed in order for a transaction to be commited.

specifies a list of public keys and signatures for those keys and a sequential
list of instructions that will operate over the states associated with the
account keys. For the transaction to be committed all the instructions must
execute successfully; if any abort the whole transaction fails to commit.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"abort" sounds like something specific but there is no information about what that may be. Might use the word "fail" here instead.

book/src/runtime.md Outdated Show resolved Hide resolved
book/art/tvu-runtime.bob Outdated Show resolved Hide resolved
book/art/runtime.bob Outdated Show resolved Hide resolved
book/src/runtime.md Outdated Show resolved Hide resolved
@garious garious merged commit 7ce9c0a into solana-labs:master Feb 20, 2019
jstarry pushed a commit to jstarry/solana that referenced this pull request Aug 26, 2024
* build(deps): bump serde_json from 1.0.125 to 1.0.127

Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.125 to 1.0.127.
- [Release notes](https://github.com/serde-rs/json/releases)
- [Commits](serde-rs/json@1.0.125...1.0.127)

---
updated-dependencies:
- dependency-name: serde_json
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>

* Update all Cargo files

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
jeffwashington pushed a commit to jeffwashington/solana that referenced this pull request Aug 27, 2024
* build(deps): bump serde_json from 1.0.125 to 1.0.127

Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.125 to 1.0.127.
- [Release notes](https://github.com/serde-rs/json/releases)
- [Commits](serde-rs/json@1.0.125...1.0.127)

---
updated-dependencies:
- dependency-name: serde_json
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>

* Update all Cargo files

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants